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(54) Public key infrastructure 

(57) A public key infrastructure (PKI) (30) includes 
a subject (34). a verifier (36), and certificate authority 
(32) that Issues a first unsigned certificate (60) to the 
subjectthat binds a public key (62) of the subject to long- 
tenn identification infomiation (63) related to the subject 
and maintains a certificate database (40) of unsigned 
certificates in which It stores ttie first unsigned certifi- 
cate. The verifier maintains a hash table (42) containing 



cryptographic hashes of valid unsigned certificates cor* 
responding to the unsigned certificates stored in the cer- 
tificate database and including a cryptographic hash of 
the first unsigned certificate. The subject presents the 
issued first unsigned certificate to the verifier for authen- 
tication and demonstrates ttiat ttie subject has knowl- 
edge of a private key corresponding to the public key 
(46) in the unsigned certificate. 
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Description 

[0001 ] This patent application is related to the follow- 
ing Non-Provisional U.S. Patent Applications: Serial 
Number 09/483,185, entitled "AUTHORIZATION IN- 5 
FRASTRUGTURE BASED O PUBLIC KEY CRYPTOG- 
RAPHY". Serial Number 09/483,366, entitled "LIGHT- 
WEIGHT PUBLIC KEY INFRASTRUCTURE EMPLOY- 
ING DISPOSABLE CERTIFICATES", and Provisional 
U.S. Patent Application Serial Number 60/1 76,157. en- io 
titled "PUBLIC KEY VALIDATION SERVICE", which 
were all filed on even date herewith and are all assigned 
to the same assignee as the present application; and 
European patent application no. 0031 0771 .1 . 
[0002] The present invention relates to public key 15 
cryptosystems, and more particularty. to a public key In- 
frastructure employing unsigned certiffcates for authen- 
tk»tion. 

[0003] Public key cryptosysten^ are globally de- 
ployed on the Worid Wide Web, as well as on a growing 20 
number of enterprise networks, for establishment of se- 
cure communteation channels. Every user in a public 
key cryptosystem has a pair of keys Including a public 
key and a private key. The publb key Is disclosed to oth- 
er users while the private key Is kept secret. A public 25 
key cryptosystem typically has a primary designed use, 
such as for encryptton. digital signature, or key agree- 
ment. Public key cryptosystems are also used for user 
authentteation. For example, a user can authentteate it- 
self to other users by demonstrating knowledge of its 30 
private key. which other users can verify using the cor- 
responding public key 

[0OO4] In an application of a public key cryptosystem 
for authenticating a user, the public key must be secure- 
ly associated with the identity of the user that owns the 35 
public key by authenticating the public key itself. Public 
key certifteates are typbally employed to authenticate 
the public key. A public key certificate is a digital docu- 
ment, signed by a certificate authority, that binds a public 
key with one or more attributes that uniquely identify the ^ 
owner of the publk: key The public key certlfk^ate can 
be verified using the certffk:ate authority's publto k^, 
whk:h is assumed to be well known or is recurshfety cer- 
tified by a higher authority. For example, in a corpora- 
tion, a public key certificate can bind a pubic key to an ^ 
employee number. 

[0005] A publk: key infrastru(^re (PKi) refers to the 
colle^on of entities, data structures, and procedures 
used to authenticate public keys. A traditional PKI com- 
prises a certificate authority, publfc key certificates, and so 
procedures for managing and using the pubib key cer- 
tificates. 

[0006] One type of a user of a PKI owns tiie public 
key contained in a public key certifteate and uses the 
certificate to demonstrate the user's identity. This type ss 
of user is refeaed to as tiie subject of the certifk:ate or 
more generally as the subject. Another type of user re- 
lies on a public key certifk:ate presented by anotiier user 



to verify that the other user is tiie subject of the certifi- 
cate and that the attributes contained in the certificate 
apply to the other user. TTiis type of user that relies on 
tiie certificate Is referred to as a verifier or relying party. 
[0007] The association between a pubite key and an 
identity can t>ecome invalid because the attributes that 
define the kientity no longer apply to the owner of the 
public key, or because the private key that con^csponds 
to the public key has been compromised. A PKI typk:ally 
employs two complementary techniques for dissociat- 
ing a publb key from an kjentity. In the first technique, 
each publk: key certificate has a validity period defined 
by an expiration date, which is a sut)stantial period from 
the issue date, such as one year from the issue date. In 
ttie second technique, the certifteate authority revokes 
a public k^certifbate if tiie public key certificate's bind- 
ing becomes invalid before the expiration date. One way 
of revoking a public key certificate is by including a serial 
number of the pubib key certifk:ate in a certificate rev- 
ocation list (ORL), whteh is signed and issued by tiie cer- 
tificate authority at known periods Intervals, such as 
every few hours or once a day. An entity that relies on 
a certificate is responsible for obtaining the latest ver- 
sion of the CRL and verifying that the serial number of 
tiie publb key certificate Is not on the list 
[0008] CRLs typically become quite long very quickly. 
When the CRLs become long, perfomiance is severely 
Impacted. Rrst, CRL retrieval consumes large amounts 
of network bandwidth. Second, each application has to 
retrieve the CRL periodically, parse the CRL, and allo- 
cate storage for tiie CRL. Then, the application needs 
to carry out a linear search of the CRL for the public key 
certificate serial number when the application verifies 
each publk; key certificate. As a result, conventional 
PKIs do not scale beyond a few thousand users. 
[0009] One solution proposed to alleviate the linear 
search problem is to partition CRl^. The serial number 
of the publk: key certificate detemiines where the CRL 
partition is located when the public key certificate Is re- 
voked. With partitioned CRLs, the applk^ation still has to 
retrieve and store the entire CRL or else the application 
needs to fetch a CRL partition in order to verify a certif- 
fcate. Since certif fcate verification is a likely critical path , 
fetching a CRL partition impacts the time it takes to run 
ttie applk^ion. 

[0010] An on-line certificate status protocol (OCSP) 
operates by pemnltting ttie verifier of the public key cer- 
tifk:ate to ask the certificate authority if the certificate is 
cun-ently valid. The certificate authority responds with a 
signed statement. The OCSP allows CRLs to be avoid- 
ed, but requires ttie verifier to query the certificate au- 
thority as part of the transaction that employs the publk: 
key certificates. The verifier querying the certificate au- 
thority increases the time it takes to perform the trans- 
action. The OCSP scheme is highly vulnerable to a de- 
nial-of-servbe attack, where the attacker floods the cer- 
tifk»teauthority with queries. Respondingto each query 
is computationally expensive, because each response 
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requires a digital signature. 

[001 1 ] In a certificate status proofs scheme, the cer- 
tificate authority maintains a data structure describing 
the set of valid and Invalid certificates in the directory. 
For every public key certificate that has not yet expired, s 
a short cryptographic proof can be extracted from the 
data structure of the certificate's current status (i.e., val- 
id or Invalid) . A CRL can essentially be viewed as a cryp- 
tographic proof of invalidity for the public key certificates 
in the CRL, and proof of validity for those not in the CRL « 
The CRL, however, Is not a short proof. The short cryp- 
tographic proof can be obtained by the verifier from the 
directory, or it can be obtained by the subject and pre- 
sented to the verifier together with the public key certif- 
icate. 15 
[0012] The Simple Public Key Infrastructure (SPKI) 
working group of the Internet Society and the Intemet 
Engineering Task Force has proposed the possibility of 
employing short-lived certificates as a method of achiev- 
ing fine-grain control over the validity Interval of a cer- 20 
tificate. See CM. Ellison, B. Frantz, B. Lampson, R. 
Rivest, B.M. Thomas and T. Ylonen, SPKI CerUrmte 
Theory, Request for Comments 2560 of the Intemet En- 
gineering Task Force, September 1999. The SPKI cer- 
tificate theory reference states that there are cases in 25 
which a short-lived certifk:ate requires fewer signatures 
and less networktraffic than various on-line test options. 
The use of a short-lived certificate always requires fewer 
signature verif Nations than the use of a certificate plus 
on-line test result. 30 
[0013] Nevertheless, no practical method of issuing 
short-lived certifk:ates has been proposed. Traditional 
certificates are issued off-line, as part of a process that 
Includes subject registration, at the rate of one per year 
per user. By contrast, short-lived certificates would have 35 
to be issued on-line at the rate of at least one per day 
per user, and perhaps as often as one every few minutes 
for every user. 

[001 4] The temi on-line and the terni off-line have par- 
tbular definitions in the context of a PKI. The temi on- 40 
line herein refers to the day-to-day usage of public key 
certificates and key pairs for authentteation. The term 
off-line herein refers to the more Infrequent establish- 
ment or dissolution of publk: key bindings, which may 
result in the issuing or revocation of public key certifi- 45 
cates. For example, the traditional certificate authority 
Is off-line. Issues CRLs off-line, and places the CRLs In 
a directory for on-line retrieval. The scheme involving 
certificate status proofs also makes use of off-line cer- 
tificate authorities. The OCSP is the only scheme de- so 
scribed above that employs an on-line certif teate author- 
ity. 

[001 5] The present invention seeks to provide an lnr>- 
proved pubic key infrastructure. 

[0016] According to an aspect of the present inven- ss 
tton, there is provided a public key infrastructure as 
specified In daiml. 

[0017] According to another aspect of the present In- 



vention, there is provided a method of authenticating a 
subject as specified in claim 8. 
[001 8] The pref en'ed embodiment can provide an im- 
proved lightweight pubic key infrastructure that over- 
comes the above-described revocation problenns and Is 
more efficient and more scalable (in terms of numbers 
of certificates) than conventional PKis. 
[0019] The preferred emt>odiment provides a publfc 
key infrastmcture (PKI) that includes a subject, a verifier, 
and certificate authority. The certificate authority issues 
a first unsigned certificate to the subject that binds a 
public key of the subject to long-temi identification infor- 
mation related to the subject. The certificate authority 
maintains a certificate database of unsigned certificates 
In which It stores the first unsigned certlfcate. The ver- 
ifier maintains a hash table containing cryptographic 
hashes of valid unsigned certificates con-esponding to 
the unsigned certificates stored In the certifcate data- 
base and including a cryptographs hash of the first un- 
signed certifcate. The subject presents the issued first 
unsigned certificate to the verifier for authentication and 
demonstrates that the subject has knowledge of a pri- 
vate key corresponding to the pubic key in the unsigned 
certificate. 

IP020] In one embodiment, the first unsigned certifi- 
cate includes an expiration date/time. In one embodi- 
ment, the first unsigned certificate does not include an 
expiration date/time. 

[0021] In one embodiment, the private key is stored 
in a secure storage medium accessible by the subject, 
such as a smartcard or a secure software wallet 
[0022] In one embodiment, the verifier computes the 
cryptographic hash of the first unsigned certificate with 
a collision-resistant hash function, such as a SHA-1 
hash function or a MD5 hash function. 
[0023] In one embodiment, the certificate authority 
and the verifier operate to revokes the first unsigned cer- 
tificate when the binding of the subject's pubic key to 
the long-temfi identifcation information related to the 
subject becomes Invalid. In one embodiment, the revo- 
cation is perfomied with the following protocol. The cer- 
tificate authority retrieves first unsigned certificate from 
the certificate database and computes a cryptograph c 
hash of the first unsigned cerlifcate. The certificate au- 
thority sends a message to the verifier containing the 
cryptographic hash of the first unsigned certificate and 
requesting that the verifier remove the conresponding 
cryptographic hash of the first unsigned certifcatefrom 
its hash table. The verifier removes the cryptographc 
hash of the first unsigned certificate from its hash table 
and notifies the certif bate authority that it has removed 
the cryptographc hash of the first unsigned certifcate 
fi-om its hash table. The certif cate authority collects the 
notification sent by the verifier. 
[0024] In one emt>odiment, th e revocation protocol in- 
cludes the certifcate authority maridng the first un- 
signed certificate in the certificate database as being 
InvaIki, for auditing purposes. In an altemate embodi- 
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ment, the revocation protocol includes the certificate au- 
thority deleting the first unsigned certificate from the cer- 
tificate database. 

[0025] The prefen-ed public key infrastructure could 
be referred to as a lightweight PKt because it is substan- 5 
tially simpler and more efficient than a conventional PKI 
that employs traditional long-term certificates. In con- 
trast to the traditional long-term certificates employed 
by conventional PKIs, the unsigned certificates for au- 
thentication of the subject to the verifier are not signed, io 
do not need an expiration date, and do not use CRLs. 
The preferred PKI is also more scalable (In terms of 
numbers of certificates) than a conventional PKI. 
[0026] An embodiment of the present invention is de- 
scribed below, by way of example only, with reference is 
to the aoconr^anying drawings, in which: 

Figure 1 Is a block diagram of an embodiment of 
light-weight public key infrastructure (PKI) employ- 
ing unsigned certificates. 20 
Figure 2 is a diagram of an unsigned certificate is- 
sued from a certificate authority of the PKI of Rgure 
1. 

Figure 3 is a fiow diagram of a protocol for issuing 
an unsigned certificate from a certificate authority 25 
of the PKI of Rgure 1. 

Figure 4 is a flow diagram illustrating a protocol for 
a subject to demonstrate its klentity to a verifier of 
the PKI of Figure 1. 

Figure 5 is a fiow diagram illustrating a protocol for so 
a certificate authority to revoke an unsigned certifi- 
cate for the PKI of Rgura 1 . 
Figure 6 is a block diagram of a computer system 
and a corresponding computer readable medium in- 
corporating one or more main software program 35 
components of a PKI. 

[0027] I n the following detailed description of the pre- 
ferred embodiments, reference is made to the accom- 
panying drawings which form a part hereof, and in which 40 
is shown by way of illustration specific embodiments in 
whbh the invention may be practiced. It is to be under- 
stood that other embodiments may be utilized and struc- 
tural or logical changes may be made without departing 
from the scope of the present invention. The following ^ 
detailed description, therefore, is not to be taken in a 
limiting sense, and the scope of the present inventton Is 
defined by the appended claims. 
[0028] An embodiment of light-weight public key in- 
frastructure (PKI) is illustrated generally at 30 in Rgure so 
1 . PKI 30 includes several main components which are 
each a software program. The main software program 
components of PKI 30 run on one or more computer sys- 
tems. In one embodiment, each of the main software 
program components runs on its own computer system. 55 
[0029] A certificate authority 32 issues unsigned cer- 
tificates to one or more subjects, such as subject 34. 
Subject 34 is a user which owns a pubtk: k^ cdntained 



in the unsigned certificate and uses the unsigned certif- 
icate to demonstrate the subject's identity to one or more 
verifiers, such as verifier 36, by demonstrating that the 
subject has knowledge of a private key corresponding 
to the publto key in the unsigned certificate. Verifier 36 
is a user whbh relies on the unsigned certifcate pre- 
sented by subject 34 to verify that subject 34 is the sub- 
ject of the unsigned certificate and that the attributes 
contained in the unsigned certificate apply to subject 34. 
[0030] In some embodiments of PKI 30, the same us- 
er can play the role of subject 34 and verifier 36 in dif- 
ferent situations. This embodiment, however, is partic- 
ularly beneficial In situations where subjects and verifi- 
ers f omi two distinct classes of users where the dass of 
verifiers is relatively small (e.g. , up to a few hundred ver- 
ifiers) while the dass of subjects can be very large (e. 
g., up to millions of subjects). 

[0031 ] PKI 30 does not issue traditional long-temri cer- 
tificates, such as issued by conventional PKIs. Tradi- 
tional long-term certificates are signed by a certifteate 
authority and bind a public key of the subje<^ with one 
or more attributes that uniquely identify the subject. Tra- 
ditional long-temfi certifk^ates typically have a validity 
period defined by an expiration date, which is a sut>stan- 
tial period from the Issue date, such as one year from 
the issue date. A conventional certifteate authority 
needs to revoke a traditional long4emi certificate if the 
public key certificate binding becomes invalid before the 
expiration date. As discussed above, a variety of meth- 
ods have been used to revoke traditional long-term cer- 
tificates, such as by using a certificate revocation list 
(CRL) or an on-line certificate status protocol (OCSP). 
P)032] PKI 30 is refen-ed to as being a lightweight PKI 
because it is substantially simpler and more effident 
than a conventional PKI that employs traditional long- 
temi certificates. In contrast to the traditional long-term 
certificates emptoyed by conventional PKIs, the un- 
signed certificates for authentcation of subject 34 to ver- 
ifier 36 are not signed, do not need an expiration date, 
and do not use CRLs. The PKI 30 is also more scalable 
(in terms of numbers of certificates) than a conventional 
PKI. 

[0033] Certificate authority 32 maintains a certificate 
database 40 containing unsigned certificates. Each un- 
signed certificate in certif bate database 40 binds a pub- 
lic key of a subject, such as subject 34. to one or more 
attributes ttiat uniquely identify tiie subject. 
[0034] Verifier 36 maintains a hash table 42 contain- 
ing cryptographic hashes of valid unsigned certiffcates. 
Each cryptographic hash in hash table 42 is computed 
from an unsigned certifk:ate using an agreed upon col- 
lision-resistant hash function, such as SHA-1 or MD5. 
Hash table 42 is essentially a list of the cun-entiy valid 
unsigned certificates which is keyed by the cryptograph- 
ic hash. Cryptographs hashes function well as keys for 
hash table 42, because cryptographic hashes behave 
statistically as random quantities. 
[0035] Subject 34 has a private-key 46 stored in a se- 
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cure storage medium 48, such as a smartcard or secure 
software wallet. Subject 34 also has a public key math- 
ematically associated with private key 46 as specified 
by a public key ctyptosystem. Subject 34 registers the 
public key corresponding to private key 46 with certifi- 
cate authority 32 by sending the public key and one or 
more attributes that uniquely identify subject 34's iden- 
tity to certificate authority 32 and demonstrating that the 
identif bation attributes apply to subject 34. Examples of 
such identif k^ation attributes include name, social secu- 
rity number, and employee number 
[0036] The components of PKI 30 are linked by one 
or more computer networks. A network connection 50 
couples certificate authority 32 and subject 34. A net- 
wori( connection 52 couples subject 34 and verifier 36. 
A network connection 54 couples certificate authority 32 
and verifier 36. Networic connection 54 is preferably a 
secure networit connection, such as a Secure Sockets 
Layer (SSL) connection, to properly protect communi- 
cations between certificate authority 32 and verifier 36. 
In one embodiment, secure network connec^on 54 pro- 
vides data integrity protection, including data origin au- 
thentication, and anti-replay protection. 
[0037] One embodiment of an unsigned certificate is- 
sued by certifk:ate authority 32 is Illustrated generally at 
60 in Figure 2. Unsigned certifk:ate 60 includes a meta- 
data (MD) field 61 containing data about unsigned cer- 
tificate 60 Itself rather than data related to the subject. 
Examples of data stored in meta-data field 61 include 
serial number and issuer name. Unsigned certificate 60 
includes a subjecrs publk: key (PK) 62. Unsigned cer- 
tificate 60 includes bng-term identification infomnatjon 
(LTI) field 63 containing attributes uniquely identifying 
the subject, such as the subjects name, the subject's 
social security number, or the subject's employee 
number, 

[0038] Unsigned certificate 60 optionally includes a 
long-term expiration (EXP) field 64 which contains a 
dateAime of expiration for unsigned certif k:ate 60. The 
expiration date/lime contained in long-temi expiration 
field 64 is useful for administrative purposes, but is not 
required for proper functioning of PKI 30. By contrast, 
in a conventional PKI, the expiration date Is required to 
reduce the size of the CRL as revoked certificates reach 
their expiration dates. 

[0039] A protocol for issuing unsigned certifbate 60 
from certificate authority 32 is Illustrated generally at 1 00 
in Figure 3. At step 102, subject 34 sends its publb key 
and one or more attributes that uniquely identify subject 
34 to certifrcate authority 32. 
[0040] At step 103, subject 34 demonstrates knowl- 
edge of the private key 46 associated with the subject 
34's pubKc key. Step 103, Is performed In a way that 
depends on the cryptosystem for which the private-pub- 
ic key pair has been generated by subject 34. For ex- 
ample, in a digital signature cryptosystem, subject 34 
demonstrates knowledge of the private key 46 by using 
private key 46 to digitally sign a quantity derived from a 



random quantity generated by certificate authority 32. 
Certificate authority 32 then verifies this digital signature 
using subject 34*s publk: key. 

[0041] At step 1 04, subject 34 demonstrates to certif- 
5 teate authority 32, by out-of-band administrative means, 
ttiat the identificatbn attributes sent in step 102 apply 
to subject 34. 

[0042] At step 1 06, certificate authority 32 creates un- 
signed certificate 60 and stores unsigned certificate 60 

10 in certificate database 40. At step 108, certif teate au- 
thority 32 sends unsigned certificate 60 to subject 34. 
[0043] At step 1 1 0, certificate authority 32 computes 
a cryptographte hash of unsigned certificate 60 using an 
agreed upon collision-resistant hash function, such as 

« SHA-1 or MD5. In step 110. certif bate authority 32 
sends the computed cryptographic hash of unsigned 
certificate 60 to verifier 36 over networic connection 54, 
which provides data integrity protection, such as with an 
SSL connection. Secure networic connec^on 54 pre- 

20 vents an attacker from tricking verifier 36 into accepting, 
and adding to hash table 42, a cryptograph^ hash of 
unsigned certif teate 60 that has not been issued by cer- 
tificate authority 32 or is no longer valid. 
[0044] Atstep 112, verifier 36 stores the cryptographfc 

25 hash of unsigned certificate 60 computed In step 1 1 0 in 
hash table 42. 

[0045] A protocol employed by subject 34 to demon- 
strate its Identity to verifier 36 is illustrated generally at 
200 in Figure 4. At step 202, subject 34 sends a mes- 

30 sage to verifier 36 containing unsigned certificate 60. 
[0046] At step 204, if a long-term expiration field 64 is 
present in unsigned certificate 60, verifier 36 verifies 
that the expiration date/time specified in long-term ex- 
piration field 64 has not been reached. 

35 [0047] At step 206, verifier 36 computes a crypto- 
graphk: hash of unsigned certificate 60 by the agreed 
upon collision-resistant hash function, in step 206, ver- 
ifier 36 then verifies that the computed cryptographk; 
hash is present in hash table 42. In step 206, verifier 36 

40 periomis a look-up of hash table 42 with an efficient and 
computationally inexpensh^e operation. Moreover, since 
unsigned certificate 60 is not signed, certif »ate authority 
32 does not perfonn a computationally expensive sig- 
nature operation to create unsigned cerirfk:ate 60 and 

45 verifier 36 does not perform a computationally expen- 
sive signature verification operation as part of the vali- 
dation of unsigned certificate 60. 
[0048] At step 208, subject 34 demonstrates knowl- 
edge of the private key 46 associated with the publfc key 

50 62 contained in unsigned certif k^te 60. Step 208 Is per- 
formed in a way that depends on the cryptosystem for 
which the private/publk: key pair has been generated by 
subject 34. For example, In a digital signature crypto- 
system, subjecrt 34 demonstrates knowledge of the pri- 

55 vate key 46 by using private key 46 to digitally sign a 
quantity derived from a random quantity generated by 
verifier 36. Verifier 36 then verifies this digital signature 
using the public key 62 in unsigned certrfk^te 60. 
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[0049] A protocol for revoking unsigned certificate 60 
is illustrated generally at 300 in Rgure 5. Protocol 300 
Is performed when subject 34's private key 46 is com- 
promised or the identrfication attributes in long-term 
identification infonnation field 63 no longer apply to sub- s 
ject 34, because in either case the binding of public key 
62 to the identification attributes is invalid. 
[0050] At step 302. certificate authority 32 retrieves 
unsigned certificate 60 from certifk:ate datat>ase 40 and 
computes a cryptograph^ hash of unsigned certificate io 
60 using the agreed upon collision-resistant hash func- 
tion. In one embodiment, certificate authority 32 marks 
unsigned certiffcate 60 in certificate database 40 as be- 
ing invalid, for auditing purposes. In an alternative em- 
bodiment, where retention of unsigned certificate 60 In '5 
certificate database 40 is not required for auditing pur- 
poses, certrfbate authority 32 deletes unsigned certifi- 
cate 60 from certificate database 40. 
[0051] At step 304, certificate authority 32 sends a 
message to each verifier 36 containing the cryptograph- 20 
ic hash of unsigned certif k»te 60 computed in step 302. 
The message sent in step 304 also requests that each 
verifier 36 remove the con^esponding cryptographic 
hash of unsigned certificate 60 from its hash table 42. 
[0052] At step 306, each verifier 36 removes the cryp- 25 
tographtc hash of unsigned certiftoate 60 from its hash 
table 42 which corresponds to the cryptographic hash 
sent in the message from certificate authority 32 in step 
304. In step 306, each verifier 36 notifies certificate au- 
thority 32 that it has removed the cryptograph^ hash of 30 
unsigned certificate 60 from its hash table 42. The noti- 
fication perfonned In step 306 is sent to certificate au- 
thority 32 over secure networic connection 54 to prevent 
an attacker from sending a false notification to certifk^ate 
authority 32. 35 
[0053] At step 308, certif bate authority 32 collects the 
notifications sent by each verifier 36 In step 306. In step 
308, certificate authority 32 deems that the revocation 
of unsigned certifteate 60 is completed when notifk:a- 
tions are received fi-om all of the verifiers 36. 40 
[0054] Once protocol 300 is completed, unsigned cer- 
tificate 60 will not be accepted by any verifier 36 and will 
therefore become useless. 

[0055] Protocol 300 for PKI 30 is practfcal only when 
there are a small number of verifiers 36 (e.g., up to a 45 
few hundred verifiers). If there are a small number of 
verifiers 36, it is likely that all of verifiers 36 will receive 
the request firom certifbate authority 32 in step 304 of 
protocol 300, remove the cryptographfc hash in step 
306, and retum the acknowledgment (i.e., notification) so 
in step 308. If one or two verifiers 36 fall to return an 
acknowledgment, an administrator of certificate author- 
ity 32 can investigate and manually conrect the cause of 
the failure. 

[0056] Figure 6 illustrates one embodiment of a conrv ss 
puter system 250 and an external computer readable 
medium 252 which can be employed 
[0057] to implement one or more of the main software ' 



program components of a light-weight PKI, such as PKI 
30. Embodiments of external computer readable medi- 
um 252 Include, but are not limited to: a CD-ROM , a flop- 
py disk, and a disk cartridge. Any one of the main soft- 
ware program components of a light-weight PKI accord- 
ing to the present invention can be implemented in a 
variety of compiled and interpreted computer languag- 
es. Extemal computer readable medium 252 stores 
source code, object code, executable code, shell scripts 
and/or dynamb link libraries for any one of the main soft- 
ware program components of a light-weight PKI. 
[0058] An input device 254 reads extemal computer 
readable medium 252 and provides this data to compu- 
ter system 250. Embodiments of input device 254 in- 
clude but are not limited to: a CD-ROM reader, a floppy 
disk drive, and a data cartridge reader. 
[0059] Computer system 250 includes a central 
processing unit 256 for executing any one of the main 
software program components of a light-weight PKI. 
Computer system 250 also includes local disk storage 
262 for locally storing any one of the main sofhvare pro- 
gram components of a light-weight PKI before, during, 
and after execution. Any one of the main software pro- 
gram components of a light-weight PKI also utilizes 
memory 260 within the computer system during execu- 
tion. Upon execution of any one of the main software 
program components of a light-weight PKI output data 
IS produced and directed to an output device 258. Em- 
bodiments of output devbe 258 include, but are not lim- 
ited to: a computer display devbe, a printer, and/or a 
disk storage device. 

[0060] The disclosures in United States patent appli- 
cation no. 09/483,186, from which this application 
claims priority, and in the absti-act accompanying this 
application are Incorporated herein by reference. 



Claims 

1 . A public key infrastructure (30) comprising: 
a subject (34); 

a certifbate authority (32) operable to issue a 
first unsigned certificate (60) to the subject that 
binds a publk: key (62) of the subject to long- 
term identifk^tion infomnation (63) related to 
the subject, the certif teate authority maintaining 
a certificate database (40) of unsigned certifi- 
cates in whrch it stores the first unsigned certif- 
icate; and 

a verifier (36) for maintaining a hash table (42) 
containing cryptographk: hashes of valid un- 
signed certlfbates corresponding to the un- 
signed certificates stored in the certifbate da- 
tabase and including a cryptograph^ hash of 
the first unsigned certiftoate, wherein the sub- 
ject presents the issued first unsigned certifi- 
cate to the verifier for authentication and dem- 



6 



11 



EP1 117206 A2 



12 



onstrates that the subject has knowledge of a 
private key (46) corresponding to the public key 
in the unsigned certificate. 

2. A publk: key infrastruc^re as in daim 1 , wherein the s 
first unsigned certificate includes an expiration 
date^me. 

3. A public key Infrastructure as in claim 1 , wherein the 
first unsigned certificate does not include an expi- io 
ration date/time. 

4. A public key infrastruc^re as in dalm 1 , 2 or 3, 
wherein the certificate authority and the verifier op- 
erate to revoke the first unsigned certificate when is 
the binding of the subject's pubib key to the long 
term identiftoation infomraation related to the subjed 
becomes invalid. 

5. A public key Infrastructure as in claim 4, wherein the 20 
certifnate authority and the verifier operate to per- 
fomn the revocation protocol to revoke the first un- 
signed certifteate, the revocation protocol including: 

the certifk^te authority retrieving first unsigned 25 
certificate from the certificate database and 
computing a cryptographic hash of the first un- 
signed certificate; 

the certificate authority sending a message to 
verifier containing the cryptographic hash of the 30 
first unsigned certificate and requesting that the 
verifier remove the corresponding cryptograph- 
ic hash of the first unsigned certif bate from its 
hash table; 

the verifier removing the cryptographs hash of 35 
the first unsigned certificate from its hash table 
and notifying the certif bate authority that it has 
removed the cryptographic hash of the first un- 
signed certifbate from its hash table; and 
the certificate authority collecting the notifba- 40 
tion sent by the verifier. 

6. A public key infrastructure as In claim 5, wherein the 
revocation protocol Includes the certificate authority 
maridng the first unsigned certifbate In the certifi- 45 
cate database as being invalid, for auditing purpos- 
es. 

7. A public key Infrastructure as in claim 5, wherein the 
revocation protocol includes the certificate authority so 
deleting the first unsigned certificate from the cer- 
tificate database. 

8. A method of authentbating a subject (34) to a ver- 
ifier (36) in a public key infrastructure (30), the meth- ss 
od comprising the steps of: 

Issuing a first unsigned certificate (60) from a 



certificate authority (32) to the subject that 
binds a public key (62) of the subject to long- 
term Identification infonmation (63) related to 
the subject; 

maintaining, at the certificate authority, a certif- 
icate database (40) of unsigned certificates; 
storing the first unsigned certificate in the cer- 
tificate database; 

maintaining, at the verifier, a hash table (42) 
containing cryptographb hashes of valid un- 
signed certffbates corresponding to the un- 
signed certificates stored in the certifbate da- 
tabase and Including a cryptographb hash of 
the first unsigned certifbate; 
presenting the Issued first unsigned certificate 
from the subject to the verifier for authentica- 
tion; 

demonstrating, by the subject, that the subjed 
has knowledge of a private key (46) corre- 
sponding to the pubib key in the unsigned cer- 
tificate. 

9. A method as In dalm 8, wherein the first unsigned 
certificate includes an expiration date/time. 

10. A method as in daim 8, wherein the first unsigned 
certificate does not Indude an expiration date/time. 

1 1 . A method as in claim 8, 9 or 1 0, comprising the step 
of: 

revoking the first unsigned certifbate when 
the binding of the subject's pubIb key to the long- 
term identification Information related to the subject 
becomes invalid. 

12. A method as in claim 11 , wherein the revoking step 
Includes the steps of: 

retrieving first unsigned certificate from the cer- 
tificate database an6 computing a cryptograph- 
b hash of the first unsigned certificate; 
sending a message from certifbate authority to 
verifiercontaining the cryptographic hash of the 
first unsigned certifbate; 
requesting that the verifier remove the corre- 
sponding cryptographb hash of the first un- 
signed certificate from its hash table; 
removing the cryptographb hash of the first un- 
signed certificate from the hash table; 
notifying the certificate authority that the cryp- 
tographic hash of the first unsigned certificate 
is removed from the hash table; and 
collecting, at the certifbate authority, the notifi- 
cation sent In the notifying step. 
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SUBJECT SENDS ITS PUBLIC KEY 
AND IDENTIFICATION ATTRIBUTES 
TO CERTIFICATE AUTHORITY 
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SUBJECT DEMONSTRATES 
KNOWLEDGE OF THE PRIVATE KEY 
ASSOCIATED WITH ITS PUBLIC KEY 
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SUBJECT DEMONSTRATES TO 
CERTIFICATE AUTHORITY THAT 
IDENTIFICATION ATTRIBUTES 
APPLY TO SUBJECT 
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CERTIFICATE AUTHORITY CREATES 

UNSIGNED CERTIFICATE AND 
STORES UNSIGNED CERTIFICATE IN 
CERTIFICATE DATABASE 
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CERTIFICATE AUTHORITY SENDS 
UNSIGNED CERTIFICATE TO SUBJECT 
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CERTIFICATE AUTHORITY 
COMPUTES CRYPTOGRAPHIC HASH 
OF UNSIGNED CERTIFICATE 


— 110 


> 


f 


VERIFIER STORES CRYPTOGRAPHIC 
HASH COMPUTED IN STEP 110 IN ITS 
HASH TABLE 
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SUBJECT SENDS MESSAGE TO 
VERIFIER CONTAINING UNSIGNED 
CERTIFICATE 



IF EXPIRATION FIELD IS PRESENT 
IN UNSIGNED CERTIFICATE. 
VERIFIER VERIFIES THAT 
EXPIRATION DATE/riME IN 
EXPIRATION FIELD HAS NOT 
EXPIRED 
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VERIFIER COMPUTES THE 
CRYPTOGRAPHIC HASH OF THE 
UNSIGNED CERTIFICATE AND 
VERIFIES THAT THE COMPUTED 
CRYPTOGRAPHIC HASH IS 
PRESENT IN HASH TABLE 



SUBJECT DEMONSTRATES 
KNOWLEDGE OF THE PRIVATE 
KEY ASSOCIATED WITH THE 
PUBLIC KEY IN THE UNSIGNED 
CERTIFICATE 
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CERTIFICATE AUTHORITY OBTAINS 
UNSIGNED CERTIFICATE FROM 
CERTIFICATE DATABASE AND 

COMPUTES CRYPTOGRAPHIC HASH 
OF THE UNSIGNED CERTICICATE 



J 

CERTIFICATE AUTHORITY SENDS A 

MESSAGE TO EACH VERIFIER 
CONTAINING THE CRYPTOGRAPHIC 
HASH COMPUTED IN STEP 402 AND 
REQUESTS THAT EACH VERIFIER 
REMOVE THE CRYPTOGRAPHIC 
HASH FROM ITS HASH TABLE 



EACH VERIFIER REMOVES THE 
CRYPTOGRAPHIC HASH RECEIVED IN 
STEP 304 FROM ITS HASH TABLE AND 
NOTIFIES CERTIFICATE AUTHORITY 
THAT THE CRYPTOGRPAHIC HASH IS 
REMOVED FROM ITS HASH TABLE 



CERTIFICATE AUTHORITY COLLECTS 
THE NOTIFICATIONS SENT BY EACH 
VERIFIER IN STEP 306 AND DEEMS 
THAT THE REVOCATION OF 
UNSIGNED CERTIFICATE IS 
COMPLETED WHEN NOTIFICATIONS 
ARE RECEIVED FROM ALL VERIFIERS 
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